libgfxinit/nativegfx init: efifb enforced fb (+coreboot ramstage enabled bootsplash) #1403
Conversation
|
This ugly PoC now works and boots on x230-maximized, with lotsa screen tearing. @JonathonHall-Purism if you have any insights, or want to reuse parts of this or wnat me to test things, let me know! This is hard to compare against 4.14 here, but the x230-maximized rom here has 500kb freer then the 4.14 rom on master. As said earlier, qemu is not able to refresh the qemu gtk drawer for some obsuce reason on latest version provided by debian-11 |
…ch doesn't refresh qemu on top of qemu here. Would be nice if host's ttys0 was redirected to host calling qemu, but unrelated. Waiting for linuxboot#1403 to be tested on kvm and upgrading to debian-12 myself to see if bug resolved inside of qemu. Nice work there!
…ch doesn't refresh qemu on top of qemu here. Would be nice if host's ttys0 was redirected to host calling qemu, but unrelated. Waiting for linuxboot#1403 to be tested on kvm and upgrading to debian-12 myself to see if bug resolved inside of qemu. Nice work there!
|
Next steps:
Also, fbwhiptail per this savage PoC is currently launched in single buffer mode(FBWHIPTAIL_LINUXFB_SINGLE=1 fbwhiptail...) from patched whiptail script wrapper under fbwhiptail patch against git master version which also savagely rips error management when vsync ioctl happens and when panning is expected to be possible on fb buffer. To have proper double size buffer:
|
|
Interesting: simple DRM is provided in kernel 5.14+
. Check if back ported into 5.10.178 and test, otherwise if work and only provided in later version, might be good reason to kernel version bump (to use fbwhiptail in DRI mode and not linuxfb mode). See https://source.puri.sm/firmware/fbwhiptail/-/commits/1.1/ Edit: this commit seems to shed some light on error I get on qemu of debian-12 torvalds/linux@7fcf193 Seems like simpledrm might be the answer of lack of refresh with VGA std on qemu.To be tested: two birds one stone. |
Unfortunately, drivers/gpu/tiny/simpledrm.c is part if 5.15+ and wasn't back ported to 5.10.179. Also noted that bochs is part of tiny DRM support,which might be enough to have similar setup for qemu and hardware based platforms. Note that libgfxinit is only for Intel, that native init is possible (AST, AMD and others gave native gfx init under coreboot). Will need kernel bump for testing. Will try lower effort 5.15 and report back. We want LTS under Heads if possible. |
|
I think this is a great solution, and this may be a better way to get framebuffer OS boot working on the servers than more kernel hacking. I have not dug into it yet, but it sounds like fbwhiptail is using the LinuxFB backend in "single buffer" mode, which means it draws directly into the backbuffer (so you see all the drawing, this is worse than just "tearing" frames due to lack of vsync). What we need to do is adapt the shadow-buffer method of the DRI backend (in fbwhiptail 1.1) to work for LinuxFB in single buffer mode as well. So the DRI / LinuxFB part only determines where the framebuffer comes from, and in both cases we draw into a shadow buffer, then blit the contents over to the real framebuffer. I'm happy to look into it, but it'll be some time before it reaches the top of my to-do list as I have some high priority work right now. |
|
Some notes digging this down on 5.15 latest (will edit):
|
|
So simpledrm doesn't expose fb base address: simplefb does. It seems that the way to go forward would be to bump boards depending on kernel 4.14 to 5.10.5 with i915drm, have coreboot depend on libgfxinit for intel boards to show early bootsplash and have the console/fb owned by drm drivers under Heads, with in tree VLFB kexec hack (and kernel fb leak option configured, and then coreboot passing the option) so that next kexec call can reuse exposed fb address to boot even into VESA (test case working for tinycore which only contains vesafb driver and drives the console correctly. But that would need to change later on when fbwhiptail is modified to work correctly with simplefb which is the preferred unified way forward, since simplefb is able to do the same, without having drm stack into Heads kernel. |
Interesting. Can you elaborate? Should it be in |
Sorry, my recap might have been a bit too simple to sum up the whole adventure here. From what I understand, linux moved away of exposing addresses in a faster pace since 5.x. Comes 5.x which prevents leaking of fb address. inteldrm name changed to i915drmfb https://github.com/osresearch/heads/blob/master/patches/kexec-2.0.26.patch#L61, while https://github.com/osresearch/heads/blob/master/patches/kexec-2.0.26.patch#L48-L50 is now needed as well ( In the case of simpledrm, those hacks don't work and fall into this case, even if VLFB hack on kexec has simpledrm passed on https://github.com/osresearch/heads/blob/master/patches/kexec-2.0.26.patch#L95. But this works properly with simplefb (simple is the name of the driver). Basically, simpledrm, as most of the other drivers but Intel, are not respecting When libgfxinit is used, the linear framebuffer size explicit and a specially crafted jpeg of 1024x768(native size not respected since jpeg drawer doesnt support it there) linux config enabled for Under qemu-coreboot for 135, its another story, Only bochs is supported for native init to show bootspash so qemu needs to be leunahced with std vga option and nothing else to be able boot into Heads with bochs drm enabled, which doesn't kexec properly inti VESA mode for the same reasons of non-exposed fb base memory address. If simplefb path is attempted, it works. But qemu is not refereshing drawn content for unknown reasons to me. Zooming in/out shows that it worked and its possible to kexec into VESA mode as well from simplefb. And then, since Heads relies on fbwhiptail for its beautiful menus, fbwhiptail needs to be reworked a bit to work correctly with simplefb. @paulmenzel I hope those notes makes the situation a bit clearer. |
|
@paulmenzel as usual thanks for keeping an eye open like you do here. |
|
@paulmenzel any insights reading this? #1398 is PoC of enabling libgfxinit in coreboot for all slower boards to have splashscreen while SPI is read and kernel is extracted until i915drmfb inits the db itself and takes over the fb. But the general solution into getting simplefb driver is postponed. Nobody answered the call with the issue with qemu (q35) coreboot target and simplefb as of now. Know wsomeone I should direct the problem directly? TLDR: More work needed under fbwhiptail to generalize the concept and take advantage of simplefb, not caring about drm. But qemu still requires bochs in coreboot to draw bootsplash, requiring kvm/qemu to use bochs there and where linux config is not able to drive fb with simplefb, outside of the fbwhiptail issues. That should be fixed somehow, but as of now, i'm not sure how to get collaboration fixing the issue. #1398 gets things needed to easily toggle only the |
|
Next steps is to use changes for
snippet of linux config changes to be applied |
|
Interesting success with simplefb and fbwhiptail new simplefb supporting branch. Downside is since i915drmfb is not taking ownership of the console after libgfxinit fixates height x width of screen with limited size of splashscreen jpeg parser (only supports old sizes like 1024x768) then console is limited to that size (1024x768) until/if drm takes over on next kernel. Tried to question coreboot at https://matrix.to/#/!BZxDFuoBnMKnzVZwEp:libera.chat/$pQoGnN9DnokZ875fTbHiAtTc0IEVgQDycUJmB7PLulE?via=libera.chat&via=matrix.org&via=matrix.zerodao.gg let's see what happens. oooooold code https://github.com/coreboot/coreboot/blame/396201c1ef52c14777a756d1962e18251a338076/src/lib/jpeg.c |
tlaurion
force-pushed
the
libgfxinit-or-native-gfx-init_simplefb_linuxboot_splashscreen
branch
from
e867194
to
9d26752
Compare
|
Wow, today and yersterday were fruitful collaboration days with coreboot! Thanks to Nico Huber (icon on coreboot) for 3 patches: https://review.coreboot.org/c/coreboot/+/76431 and https://review.coreboot.org/c/coreboot/+/76424 and fbwhiptail patch against @JonathonHall-Purism 's fbwhiptail simplefb branch, we now have unified efifb driven graphics (FSP GOP/native gfx/libgfxinit), smaller splashscreen then native resolution support (centering instead of failing) and qemu support with same efifb driver configuration, resolving the weird issue we had prior with qemu and simplefb not refreshing qemu window (a problem that is unfixed but that nobody cared for) @JonathonHall-Purism If you want to point me to tested commit for librems, I can add them here! CC: @paulmenzel |
|
Note that the buildsystem is now producing Comparison for x230-hotp-maximized: Some analysis:
|
|
Note on kexec hack that seems unneeded: Removing efifb in kexec's VLFB fb address passing hack to next kernel: unneeded since EFI detected :) |
|
trampoline efifb https://review.coreboot.org/c/coreboot/+/76431 patch updated upstream to patchset 4, rebasing |
tlaurion
force-pushed
the
libgfxinit-or-native-gfx-init_simplefb_linuxboot_splashscreen
branch
from
75bc1cb
to
a6fba05
Compare
tlaurion
changed the title
tlaurion
changed the title
|
Was merged as patch set 6, needs rebasing |
tlaurion
force-pushed
the
libgfxinit-or-native-gfx-init_simplefb_linuxboot_splashscreen
branch
2 times, most recently
from
701452f
to
dd3a641
Compare
|
Starting cleanup of commits. |
tlaurion
force-pushed
the
libgfxinit-or-native-gfx-init_simplefb_linuxboot_splashscreen
branch
from
dd3a641
to
5f1ae72
Compare
|
Cleaning up commit logs: squash WiP commits related to legacy-flash/legacy that were not working |
- intel igpu related - remove i915drmfb hacks and use simplefb and libgfxinit enabled fb - coreboot 4.19: add patch to fix https://ticket.coreboot.org/issues/500. fbwhiptail still tears screen if in native 1366x769 though - coreboot 4.19: add patch to enable linux tampoline handle coreboot framebuffer (merged https://review.coreboot.org/c/coreboot/+/76431) - coreboot 4.19: add patch to enable coreboot to apply jpeg voodoo to create bootsplash.jpeg injected in cbfs at build time + CircleCI apt imagemagick - (Thanks Nico Huber @ICON again for above patches!) - coreboot configs: adapt VESAFB/LIBGFXINIT to use maximum fb height/width - coreboot configs for iGPU only: CONFIG_LINEAR_FRAMEBUFFER_MAX_HEIGHT CONFIG_LINEAR_FRAMEBUFFER_MAX_WIDTH to native size - coreboot configs for dGPU based on Optional VBIOS injected: VESAFB set to 1280x1024 (maximum possible). Details: coreboot configs: remove CONFIG_LINUX_COMMAND_LINE="drm_kms_helper.drm_leak_fbdev_smem=1 i915.enable_fbc=0" - Those were needed to expose i915drmfb driver prior of efifb working.
tlaurion
force-pushed
the
libgfxinit-or-native-gfx-init_simplefb_linuxboot_splashscreen
branch
from
5f1ae72
to
572573f
Compare
This comment was marked as outdated.
This comment was marked as outdated.
So if my assessment is correct: of all currently untested boards of OP. Currently, said tested boards will move to untested by the end of the week:
Other boards are currently untested and will stay like that:
TLDR: t430 and z220 boards are on the verge of being moved to untested while other boards currently untested will stay untested. |
|
Did I miss an update after #1403 (comment) ? (That one was on the Z220, didn't mention that in the reply)
|
@d-wid I take liberty to edit that comment with a link to your previous one. Thought you tested edp, didn't clicked on the link you provided myself. Let's be clearer in the future. :) kexec should be better now, less flicker! Could be used as daily driver, will land under master soon (once all boards builds successfully even if UNTESTED). Please report issues if any in seperate issue. |
|
So only t430 boards flavors are adding up to the untested boards from this PR (which are added to currently untested board list until people show up to test those and move them back out of untested boards). Moving them to untested until tested. This means what it means. They should not be flashed by general public without external flashing capability to unbrick, preferably by owners wanting the board to be fully supported and maintained as the work is done for other boards. Boards need to be tested by boards owners in a better collaboration in the future. Will try to find better ways to reach owners and willing testers and resellers.... Specific post for this PR on QubesOS forum at https://forum.qubes-os.org/t/heads-needs-testers-with-external-programmers/19564/14 |
|
Closes issue #1467 |
tlaurion
force-pushed
the
libgfxinit-or-native-gfx-init_simplefb_linuxboot_splashscreen
branch
from
9747bd0
to
ffd8e36
Compare
…files as all other boards (Otherwise, renaming board requires to rename coreboot config file as well since BOARD is used to pick corresponding one when undefined)
tlaurion
force-pushed
the
libgfxinit-or-native-gfx-init_simplefb_linuxboot_splashscreen
branch
from
ffd8e36
to
e5b64f8
Compare
|
Can confirm heads-t430-maximized-v0.2.0-1747-g572573f.rom works |
|
Will remove t430-maximized from untested board.... Thanks @srgrint for testing this out last minute prior of merging |
…ds, other t430 boards still untested
Yeah my bad, will do, |
|
heads-t430-hotp-maximized-v0.2.0-1750-g97f39a8.rom works (sorry for the delay) |
EDIT: simplefb support (previous effort) was replaced by efifb for simplicity and possible generalization of usage across FSP GOP/native gfx init/libgfxinit under coreboot/heads usage as a payload under linuxboot (without added compexity of hacking kexec, have coreboot taint kernel on linux command line options ot Heads payload).
Bonus it works also on qemu target boards (bochs native graphic init + libgfxinit).
Leaving traces below for history.Changes qemu call from -vga virtio to -vga std (to use bochs coreboot native graphic init + fb)
efifb discussions and changes from #1403 (comment) and on
Testing needed and why:
OLD (simplefb related)
537cc83 provides the changes needed to test this PR against qemu-coreboot-whiptail-tpm1 and qemu-coreboot-fbwhiptail-tpm1 on fb(no drm/dri)
Note: doesn't work properly on qemu of debian-11. Will edit once built on top of debian-12, which latest commits should permit to build without problem and then be testable on debian-12 qemu. Will update.
This gives the same current result as on x230 when enabling simplefb alone, without all drm+gpu drivers in kernel.
Excerpt of above commit log:
Limitations:
Needs cleaning. Dumping here so someone reproduces my results, mostly the limitations observed here and for a patch to be made on top of fbwhiptail so that it doesn fail on VSYNC ioctl call.